Temp changes to Environment Variables

jsarkic - Mon Nov 02 08:11:28 EST 2009
Hi Louie.

I do not believe that you can temporarily set up environment variables for the life of a session, unless you can find some way to fire a trigger when DOORS exists to reset them.

Here is a structure that is successfully working for me. At my workplace, we have at least two dozen programs using DOORS (version 7 - soon to be retired, 8 and 9), and many of these programs have both common and custom DXL scripts. We did not want to publish all of the custom scripts to all of the Programs, and we wanted only a single repository to manage these scripts. So we use the -cli command line option in the DOORS shortcuts to configure the environment variables for each Program when DOORS launches. The set-up script is launched as follows:

"<DOORSHOME>\bin\doors.exe" -o r -O r -d port@servername -cli "#include <\\common_repository\DXL\dxl_setup.inc>"

The dxl_setup.inc script determines which server is running by using:

string DOORS_Server = getenv("DOORSDATA") // Returns the DOORS server (i.e. 36677@doors_server)

Once we identify the running server, we build the addins path for the specific Program and set them using:

setenv("Projectaddins", programProjectAddins) // Project level addins
setenv("addins", programModuleAddins) // Module level addins

For our programs, we set up the following environment variable locations:

1. Location for all common scripts which are accessible to all Programs,
2. Location to C:\MyDXL for custom script development that users may be doing for themselves. This path is necessary since Security does not allow changes to files located in "C:\Program Files" where the DOORS addins directory is located,
3. Location for Program specific scripts,
4. Location for Team specific scripts on a Program. In this situation, you would look for a specific computer environment variable. If it is set on a user's computer, you can add additional Project and Module level DXL locations.

Cannot go into a lot of details in this email, but you can use this technique to fully control your environment variables when DOORS launches, configuring your variables to match a server's need. You can also do some interesting things such as scheduling a Windows task to kill all running DOORS clients when the nightly backup starts. For us, this ensures that all DOORS licenses are released and available when our servers come back online. Before we used this technique, we found that up to 20 DOORS licenses stayed checked-out on a nightly basis, with many not being release for days-on-end because users may have been out-of-office, or off on vacation.

This same code is used for all DOORS sessions on our LAN, over Citrix and using VPN.

There is much more that you can do.

It does take a bit of though and work to properly set up. But once it is running, the benefits and possibilities are vast.

Joe

llandale - Mon Nov 02 10:58:05 EST 2009
Very clever.

For those of us that lack a single common spot available to all the clients.... let me think out loud these unfinished thougts:

o -cli issues short DXL snipette to read a particular config file and eval_ it. That code includes your \\common_repository\DXL\dxl_setup.inc code, but also does file-exists check first to gage access availability. Perhaps there's more than one location to get the code; perhaps it can to clock-tick counts to see which of the various locations is the 'closest' on the network.

o Optionally, the project addins location(s) contain a single DXL, the 'runDxlConsole.dxl'. When you run that, it searches the networks to provide a console with buttons for all the relevant DXL for the current context. To run a DXL, users first run the console then push a button, rather than using the traditional pull-down menues. If the network is far away, no time is lost opening modules and building the menues (which takes up to a minute for us), but we lose that time only when the user is ready to run some DXL. I wonder if that DXL must do clever context checking, like whether a Module window or the Explorer window was the most recently used.

o Just now had some luck with this: remember the current DOORSADDINS value. Build an DxlCode string that sets DOORSADDINS to a necissary value, declares 'obj' and 'attrDXLName', reads the DXL to be run. eval_(DxlCode). Reset DOORSADDINS to its original value. Works when the DXL to run issues relative #include statements. That should work unless the DXL itself consults and depends on DOORS ADDINS.

• Louie

jsarkic - Mon Nov 02 13:50:38 EST 2009
Looks like you have grasped the potential control offered by this approach. It is highly dependent on having a common read-only repository that is accessible to everyone who is using DOORS. This provides a central location for managing single script copies, and a way to publish what you want users to have access to.

At General Dynamics Canada, we've been using this successfully for at least 3 years now.

Once you get the idea of how to control your environment at DOORS startup, you can do many other operation. For example, I've even used this technique to auto-upgrade DOORS to a newer version when a user launched DOORS for a specific server.

Even today I've had to update the startup DXL script to disable access to one hard-drive where some DXL code resides. This hard-drive happened to fill right up, causing a world of grief when DOORS launched and tried to access expected scripts. A temp fix for the entire Program took less than a minute, allowing DOORS access while the hard-drive issue is being looked into.

llandale - Mon Nov 02 14:15:16 EST 2009
A database login trigger would be nice, instead of relying on users to use the correct icon parameters. In your case, they can use a clean icon and get access to that drive.

lsand - Wed Feb 02 17:20:35 EST 2011
Related to this topic, how do you remove the customized addins directory from DOORS aside from removing the actual addins folder?

llandale - Wed Feb 02 17:40:26 EST 2011
Are you asking "From within DOORS, How can I prevent the custom Addins menu from appearing the next time I open a module?"

setenv("DOORSADDINS", "") or setenv("addins", "")

should do it; but that also sets the "addins" in the HKCU registry so its erased next time you start DOORS. Don't know how to delete a registry value from within DOORS.

I suppose you could find a way around this using a clever pre-open-module trigger (erasing it) and a post-open-module trigger (resetting it), but sheesh.

• Louie

lsand - Wed Feb 02 17:20:35 EST 2011
Related to this topic, how do you remove the customized addins directory from DOORS aside from removing the actual addins folder?

Mathias Mamsch - Wed Feb 02 19:04:37 EST 2011

I found a (little nasty) way to change the include path at runtime. I guess I better not comment on the technical details. I tested the code on DOORS 8.2 and 9.2. I guess it will work for versions in between, but you never know.

Regards, Mathias
 

pragma runLim, 10000000
 
// ................. yeah :-? ... just ignore the following lines  ...........
 
int *::+(int *p, int c) { int *q = p; q+=c; return q }
string gm (int *p, int c) { int i; string r = ""; for i in 0:(c-1) do r = r (charOf (*(p+i) & 255)) ""; return r}
int *b = addr_ 0x400000; int *p = b + *(b+0x3C); 
int s = *(p+6) & 0xFFFF, *S = (p+24+(*(p+20) & 0xFFFF)) 
int *r = S; Skip ss = createString(), sl = createString() 
int i; for i in 0:s-1 do {
    string n = gm (r , 8); int sz = *(r + 16), p = *(r + 12) 
        put (ss, n, b + p); put (sl, n, sz); r += 40
}
int dd = 0, dl = 0 
find(ss, ".data", dd ); find(sl, ".data", dl ) 
int *sr = addr_ dd, ct = 0, fa = 0 
while (ct < dl) {
   if (*sr == 0xFDE9) { fa = ct + dd; break }
   sr+=4; ct += 4
}
// .................. ok stop ignoring here  .....................................................
 
// This nice reference lets us change the includePath at runtime! 
string &includePath = addr_ (fa-8) 
 
print "Old Include Path: " includePath "\n"
ack "Put a script to c:\\temp\\test.dxl!"
 
// store the old include path 
string sOld = addr_ includePath
 
// Set the new include path to be temp 
string new = "C:\\temp"; includePath = new
 
// evaluate the test.dxl script in the new include path
eval_ "#include <test>"
 
// set back the original includePath
includePath = sOld

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

llandale - Thu Feb 03 15:35:41 EST 2011
You and I sure have different tastes in posts.

v9.2.0.1. Works the first time. 2nd time and thereafter its corrupted my addins and modules loading generate DXL errors and the native includes cannot be found. I notice the print statement herein prints also the LayoutAddins, AttrDXLAddins, and ProjectAddins separated by semi-colons and prefixed with a period-semi-colon, maybe that's the cause of this issue.

Old Include Path: .;C:\Program Files\IBM\Rational\DOORS\9.2\\lib\dxl;c:\DOORS-Stuff\DXL-Local;c:\Doors-Stuff\DXL-v9\Module;c:\Doors-Stuff\DXL-v9\Project;c:\Doors-Stuff\DXL-v9\Module\AttrLayout-Stuff\Layouts;c:\Doors-Stuff\DXL-v9\Module\AttrLayout-Stuff\AttrDXLs;c:\DOORS-Stuff\DXL-Local;c:\Doors-Stuff\DXL-v9\Project

2nd time it prints this:

Old Include Path: 4R

• Louie

SystemAdmin - Thu Feb 03 16:18:02 EST 2011
I've been using the version I posted very often and had no issues (although I've only used it with version 8.2). I don't specifically recall if I made any significant changes from Mathias's original experiment. I'm curious to know if it will work with version 9.2.

Mathias Mamsch - Wed Feb 02 19:04:37 EST 2011

I found a (little nasty) way to change the include path at runtime. I guess I better not comment on the technical details. I tested the code on DOORS 8.2 and 9.2. I guess it will work for versions in between, but you never know.

Regards, Mathias
 

pragma runLim, 10000000
 
// ................. yeah :-? ... just ignore the following lines  ...........
 
int *::+(int *p, int c) { int *q = p; q+=c; return q }
string gm (int *p, int c) { int i; string r = ""; for i in 0:(c-1) do r = r (charOf (*(p+i) & 255)) ""; return r}
int *b = addr_ 0x400000; int *p = b + *(b+0x3C); 
int s = *(p+6) & 0xFFFF, *S = (p+24+(*(p+20) & 0xFFFF)) 
int *r = S; Skip ss = createString(), sl = createString() 
int i; for i in 0:s-1 do {
    string n = gm (r , 8); int sz = *(r + 16), p = *(r + 12) 
        put (ss, n, b + p); put (sl, n, sz); r += 40
}
int dd = 0, dl = 0 
find(ss, ".data", dd ); find(sl, ".data", dl ) 
int *sr = addr_ dd, ct = 0, fa = 0 
while (ct < dl) {
   if (*sr == 0xFDE9) { fa = ct + dd; break }
   sr+=4; ct += 4
}
// .................. ok stop ignoring here  .....................................................
 
// This nice reference lets us change the includePath at runtime! 
string &includePath = addr_ (fa-8) 
 
print "Old Include Path: " includePath "\n"
ack "Put a script to c:\\temp\\test.dxl!"
 
// store the old include path 
string sOld = addr_ includePath
 
// Set the new include path to be temp 
string new = "C:\\temp"; includePath = new
 
// evaluate the test.dxl script in the new include path
eval_ "#include <test>"
 
// set back the original includePath
includePath = sOld

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

Adamarla - Mon Apr 28 06:24:02 EDT 2014

Hello Mathias,

Our IT departmant have recently decided to enable DXL Security on one of our databases. The DOORS Admins didn't want it on but were ignored. It has destroyed my workflow since I am now unable to run development code.

So far I have not found a way to change the DXL Security Home and Addins (Module or Project)

Have you found any way to change these?

Mathias Mamsch - Mon Apr 28 18:18:21 EDT 2014

There should be numerous ways to get around DXL "Security" without the need for such tricks. The easiest way would be to modify your local client to add those menus (i.e. put them in explorerAddins or somewhere). The questions is, if this would be feasible for you. The next easiest way would probably be to redirect the project addins from the server, where they are located to localhost using a 'etc/host' entry.

The include path, the DOORS Home path, the addins path are all different paths. They could probably be modified in the same way as the include path, the question would be, why you would need those menus so badly? It means quite some work to find those string constants, so the question would be, if it is really worth it.

Regards, Mathias

Adamarla - Tue Apr 29 04:28:12 EDT 2014

I am not able to modify the client install due to read only access to %programfiles%. The DOORS home directory is set to a server location by DXLsecurity. I also have no access to that.

It is not that I want to add new menu items for development, it is that I want to set the Home, Addins, etc to a local GIT Repo copy of the live code where I can develop and test before release.

I didn't think of a host entry to redirect, I'll try it. <Edit: Also unable to edit the hosts file :( >

Any idea if it is possible to close and reload the explorer withiout actually closing and restarting DOORS?

Thanks

Mathias Mamsch - Wed Apr 30 11:01:01 EDT 2014

... edit: ... lets stay with DXL Security only in this thread on not discuss general DOORS security...

An attacker could for example work on network protocol level, to simply disable the DXL Security on the fly in the network traffic. For legality reasons, I will not post an example script that shows how this is done.

An attacker could of course also make a copy of the binary and replace some strings in there. I am pretty sure, if someone would simply rename a the database option for secure dxl, that this would disable DXL security.  Of course this can also happen in memory, even triggered from DXL.

Nevertheless, I would suggest you simply use a (local) development DOORS server that has DXL security disabled for testing your scripts. Sorry that I cannot be that helpful, but as far as I know it is illegal to post a working script/receipe to circumvent a security measure.

Regards, Mathias

Adamarla - Thu May 08 09:43:48 EDT 2014

Yes, my preference would be a local server but alas Mordac The Preventer has other ideas and will not install one.

Anyway, I have half a solution so that will do.

Cheers

llandale - Thu May 08 13:02:06 EDT 2014

Have them install the Demo database on your client; then contact IBM for the "Adminstator" password of it.  When its working, thumb your nose at Schmordac the Impotent Schmuck.

While MM has outside the box ways of cercumventing things, I know of some inside the box ways.  ..err.. I mean hypothetically and theoretically.

-Louie

You could get some Attr-DXL deployed in some test module, that simply #include some test file on your client.  That file should contain the #include statement to the code you want debugged.  You can then execute the code by refreshing DXL attributes.